The present disclosure is described within the context of Long Term Evolution (LTE), i.e. Evolved Universal Terrestrial Radio Access Network (UMTS) Mobile Telecommunications System (E-UTRAN). It should be understood that the problems and solutions described herein are equally applicable to wireless access networks and user equipments (UEs) implementing other access technologies and standards. LTE is used as an example technology where the embodiments are suitable, and using LTE in the description therefore is particularly useful for understanding the problem and solutions solving the problem.
For ease of understanding, LTE Mobility is described in the following.
Radio Resource Control (RRC) (Third Generation Partnership Project (3GPP) Technical Specification (TS) 36.331, e.g. V10.8.5 (2013-01)) is the main signaling protocol for configuring, re-configuring and general connection handling in the LTE radio access network (E-UTRAN). RRC controls many functions such as connection setup, mobility, measurements, radio link failure and connection recovery. These functions are of relevance for the present disclosure, and are therefore described in some further detail below.
A UE in LTE can be in two RRC states: RRC_CONNECTED and RRC_IDLE. In RRC_CONNECTED state, mobility is network-controlled based on e.g. measurements provided by the UE. I.e. the network decides when and to which cell an UE should be handed over, based on e.g. measurements provided by the UE. The network, i.e. the LTE radio base station (called evolved Node Base station (eNodeB or eNB), respectively, in E-UTRAN) configures various measurement events, thresholds etc. based on which the UE then sends reports to the network, such that the network can make a wise decision to hand over the UE to a stronger cell as the UE moves away from the present cell.
FIGS. 1A and 1B illustrate a LTE RRC handover procedure according to 3GPP TS 36.300, e.g. V11.4.0 (2013-01), FIG. 10.1.2.1.1-1. FIGS. 1A and 1B illustrate a LTE RRC handover procedure. In a mobile network 100, a UE 102 is connected to a source eNodeB 104 of a LTE radio access network, which is controlled by a Mobility Management Entity (MME) 106 of a packet switched domain of a core network. A target eNodeB 108 is controlled by the MME 106. The user equipment 102 is exchanging data with a serving gateway 110 of the core network. During a handover, the user equipment 102 is handed over from the source eNodeB 102 to the target eNodeB 108 of the radio access network. Corresponding user data signaling is indicated by dashed arrows. L3 control signaling is indicated by dotted dashed arrows, and L1/L2 control signaling is indicated by solid arrows. The source eNodeB 104 sends in a first step 1 management control information to the user equipment 102, which in turn sends corresponding measurement reports in a step 2 to the source eNodeB 104. Thereupon, the source eNodeB 104 performs in a step 3 a handover decision, and sends a handover request in a step 4 to the target eNodeB 108. After performing admission control in a step 5, the target eNodeB 108 sends a handover request acknowledgement in a step 6 to the source eNodeB 102, which initiates a RRC connection reconfiguration in a step 7 towards the UE 100.
FIG. 2 illustrates a simplified picture of the parts of the LTE Handover (HO) procedure relevant for the disclosure. It should be noted that the HO command is in fact prepared in the Target eNB, but the message transmitted via the Source eNB. I.e. the UE sees that the message comes from the Source eNB. A mobile network 200 comprises a source eNodeB 204 and a target eNodeB 208. A UE 202 is connected to the source eNodeB 204. Subsequent to a step 210, in which a measurement configuration is sent from the source eNodeB 204 to the user equipment 202, the user equipment 202 performs in a step 212 an A3 event in which a signal strength or signal quality of the target eNodeB 208 may be detected to be better compared to a signal strength or signal quality of the source eNodeB 204, respectively, and accordingly reports in a step 214 a measurement report to the source eNodeB 204. After a corresponding handover decision in a step 216, the source eNodeB 204 sends a handover request in a step 218 to the target eNodeB 208, which in turn sends a handover acknowledgement in a step 220 to the source eNodeB 204. The source eNodeB 204 then sends in a step 222 a handover command to the user equipment 202, which performs in a step 224 a random access procedure in which dedicated preambles are submitted to the target eNodeB 208. Further arrows 226-230 relate to a completion of the handover procedure. In the step 226 an uplink (UL) grant and a Tracking Area (TA) may be sent from the target eNodeB 208 to the UE 202. In the step 228 a HO confirm may be sent from the UE 202 to the target eNodeB 208. In the step 230 a Release context may be sent from the target eNodeB 208 to the source eNodeB 204. The steps 210, 214, 216, 218, 220, 222, 224 correspond to the steps 1, 2, 3, 4, 6, 7, and 11 in FIGS. 1A and 1B.
In RRC_IDLE, mobility is handled by UE-based cell-selection, where a nomadic UE 102, 202 selects the “best” cell to camp on, based e.g. on various specified criteria and parameters that are broadcasted in the cells. For example, various cells or frequency layers could be prioritized over other, such that the UE 102, 202 tries to camp on a particular cell as long as the measured quality of a beacon or pilot in that cell is a threshold better than some other beacon or pilot received from other cells.
The present disclosure is primarily focusing on problems associated with network-controlled mobility as described above, i.e. for an LTE UE in RRC_CONNECTED state. The problems associated with failing handovers are therefore described in further detail below.
In a regular situation, and when a RRC_CONNECTED UE 102, 202 is moving out from the coverage of a first cell (also called source cell), it should be handed over to a neighboring cell (also called target cell or second cell) before loosing the connection to the first cell. I.e. it is desirable that the connection is maintained without no or minimal disruption throughout the handover, such that the end-user is unaware of the ongoing handover. In order to succeed with this, it is necessary that                the measurement report that indicates the need for mobility is transmitted by the UE 102, 202 and received by the Source eNB 104, 204, and        the Source eNB 104, 204 has sufficient time to prepare the handover to the target cell (by, among other things, requesting a handover from the Target eNB 108, 208 controlling the target cell), and        the UE 102, 202 receives the handover command message from the network, as prepared by the Target eNB 108, 208 in control of the target cell and sent via the source cell to the UE 102, 202, see FIGS. 1A, 1B, and 2.        
In addition, and in order for the handover to be successful, the UE 102, 202 must finally succeed in establishing a connection to the target cell, which in LTE requires a successful random access request in the target cell, and a subsequent HO complete message. It is noted that specifications may differ somewhat in the naming of messages. This does not limit the applicability of the present disclosure. For example, the handover command labeled as HO Command in the step 222 of FIG. 2 corresponds to the RRC Configuration Reconfiguration of the step 7 of FIG. 1A, and the handover confirm message of the step 228 of FIG. 2 corresponds to the RRC Configuration Reconfiguration Complete of the step 11 of FIG. 1A.
Thus, it is clear that in order to succeed all this, it is necessary that the sequence of events leading to a successful handover is started sufficiently early, so that the radio link to the first cell (over which this signaling takes place) does not deteriorate too much before completion of the signaling. If such deterioration happens before the handover signaling is completed in the source cell (i.e. first cell), then the handover is likely to fail. Such handover failures (HOFs) are clearly not desirable. The current RRC specification therefore provides various triggers, timers, and thresholds in order to adequately configure measurements, such that the need for handovers can be detected reliably, and sufficiently early.
In FIG. 2, the exemplified measurement report is triggered by a so called A3 event in the step 212 which, in short, corresponds to the scenario in which a neighbor cell is found to be an offset better than the current serving cell. It should be noted that there are multiple events that can trigger a report.
It may occur that a UE 102, 202 looses coverage to the cell that the UE 102, 202 is currently connected to. This could occur in a situation when a UE 102, 202 enters a fading dip, or that a handover was needed as described above, but the handover failed for one or another reason. This is particularly true if the “handover region” is very short. By constantly monitoring the radio link quality, e.g. on the physical layer as described in 3GPP TS 36.300, e.g. V11.4.0 (2013-01), TS 36.331, e.g. V11.2.0 (2013-01), and TS 36.133, e.g. V11.2.0 (2013-01), the UE 102, 202 itself is able to declare a radio link failure and autonomously start a RRC re-establishment procedure. If the re-establishment is successful, which depends, among other things, if the selected cell and the eNB 104, 108, 204, 208 controlling that cell was prepared to maintain the connection to the UE 102, 202, then the connection between the UE 102, 202 and the eNB 104, 108, 204, 208 can resume. A failure of a re-establishment means that the UE 102, 202 goes to RRC_IDLE and the connection is released. To continue a communication, a brand new RRC connection has then to be requested and established.
In the following, the features dual connectivity and RRC diversity are described.
Dual connectivity is a feature defined from the UE perspective wherein the UE may simultaneously receive and transmit to at least two different network points. The at least two network points may be connected to one another via a backhaul link such that a UE may be enabled to communicate with one of the network points via the other network point. Dual connectivity is one of the features that are being standardized within the umbrella work of small cell enhancements within 3GPP Release 12 (Rel-12).
Dual connectivity is defined for the case when the aggregated network points operate on the same or separate frequency. Each network point that the UE is aggregating may define a stand-alone cell or it may not define a stand-alone cell. In this respect, the term “stand-alone cell” may particularly denote that each network point, hence each cell, may represent a separate cell from a perspective of a UE. In contrast, network points not defining a stand-alone cell may be regarded from a perspective of a UE as one same cell. It is further foreseen that from the UE perspective the UE may apply some form of Time Division Multiplex (TDM) scheme between the different network points that the UE is aggregating. This implies that the communication on the physical layer to and from the different aggregated network points may not be truly simultaneous.
Dual connectivity as a feature bears many similarities with carrier aggregation and coordinated multi-point (CoMP). The main differentiating factor is that dual connectivity is designed considering a relaxed backhaul and less stringent requirements on synchronization requirements between the network points. This is in contrast to carrier aggregation and CoMP, wherein tight synchronization and a low-delay backhaul are assumed between connected network points.
Examples of features that dual connectivity will allow in the network are:                RRC diversity (e.g. handover (HO) command from source and/or target); in this respect, the term “RRC diversity” may particularly denote a scenario in which control signaling can be transmitted via at least two connections between a network and a UE;        Radio Link Failure (RLF) robustness (failure only when both links fail);        Decoupled uplink (UL)/downlink (DL) (UL to Low Power Node (LPN) for example with LPD corresponding to a small cell or a pico cell, DL from macro cell);        Aggregation of macro anchor carrier and LPN data booster(s);        Selective Handover (e.g., data from/to multiple nodes);        Hide UE mobility between smalls cells from Core Network (CN) with C-plane in macro cell; and        Network Sharing (Operators might want to always keep the control plane and Voice Over IP (VoIP) terminated in their own macro, but may be willing to offload best effort traffic to a shared network).        
FIG. 3 illustrates the feature of dual connectivity of a UE 302 to an anchor 304a and a booster 304b. 
A UE 302 in dual connectivity maintains simultaneous connections 334a, 334b to anchor and booster nodes 304a, 304b. As the name implies, the anchor node 304a terminates the control plane connection towards the UE 302 and is thus the controlling node of the UE 302. The UE 302 also reads system information from the anchor 304a. In FIG. 3, the system information and a spatial availability thereof are indicated by a dashed circle. In addition to the anchor 304a, the UE 302 may be connected to one or several booster nodes 304b for added user plane support. In this respect, the term “booster” may denote that a performance of a UE in terms of its data peak rate may be improved, since user plane data may be additionally transmitted via the booster. To this end, a transmission frequency employed by the anchor may be different from a transmission frequency employed by the booster.
The anchor and booster roles are defined from a UE 302 point of view. This means that a node that acts as an anchor 304a to one UE 302 may act as booster 304b to another UE 302. Similarly, though the UE 302 reads the system information from the anchor node 304a, a node acting as a booster 304b to one UE 302, may or may not distribute system information to another UE 302.
FIG. 4 illustrates a control and user plane termination in an anchor node and a booster node. This protocol architecture may represent an exemplary protocol termination compliant with dual connectivity and RRC diversity. The protocol architecture shown in FIG. 4 is proposed as a way forward for realizing dual connectivity in LTE Rel-12 in deployments with relaxed backhaul requirements. In the user plane 434 a distributed Packet Data Convergence Protocol (PDCP)/Radio Link Control (RLC) approach is taken where the booster and anchor terminate the user planes 436 of their respective bearers, with a possibility to realize user plane aggregation via Multipath Transmission Control Protocol (MPTCP) which may offer a split of traffic to several connections. In the control plane 434, the RRC and Packet Data Convergence Protocol (PDCP) are centralized at the anchor, with a possibility to route RRC messages via the anchor, the booster, or even simultaneously at both links. For ease of completeness, “NAS” may represent a Non Access Stratum protocol layer, “RLC” may represent a Radio Resource Control protocol layer, “MAC” may represent Medium Access Control protocol layer, and “PHYS” may represent a Physical layer.
In a further exemplary protocol termination enabling dual connectivity and RRC diversity, RRC is terminated in the anchor node, and PDCP is available both for the anchor node and the booster node.
However, problems described in the following might occur.
A problem may relate to handover failures and radio link failures for scenarios in which a UE is connected to one network point, hence one cell. In the following, handover and radio link failure robustness is described.
The recent and rapid uptake of Mobile Broadband has led to a need for increasing the capacity of cellular networks. One solution to achieve such a capacity increase is to use denser networks consisting of several “layers” of cells with different “sizes”: Macro cells ensure large coverage with cells encompassing large areas, while micro-, pico- and even femto-cells are deployed in hot-spot areas where there is a large demand for capacity. Those cells typically provide connectivity in a much smaller area, but by adding additional cells (and radio base-stations controlling those cells), capacity is increased as the new cells off-load the macro cells.
FIG. 5 illustrates a UE 502 moving out from a pico cell area of a pico cell 538 into macro cell area of a macro cell 540. A movement direction of the user equipment 502 is indicated by an arrow 542. This figure may illustrate a typical scenario for a handover of a UE 502.
The different “layers” of cells can be deployed on the same carrier (i.e. in a reuse-1 fashion in which all neighboring cells may use the same frequency), the small-cells could be deployed on a different carrier, and the different cells on the various layers could even be deployed using different technologies (e.g. 3G/High Speed Packet Access (HSPA) on the macro- and micro-layer, and LTE on the pico-layer as one non-exclusive example). In this respect, the term “layer” may particularly denote a higher abstraction level of a cell with respect to a transmission frequency or carrier employed in the cell.
There is currently a large interest for investigating the potential of such Heterogeneous Networks, and operators are interested in such deployments. However, it has also been found that such Heterogeneous Networks may result in an increased rate of handover failures, as briefly discussed above. One reason is that the handover region in Heterogeneous Networks may be very short, meaning that the handover might fail since the UE lost coverage to the source cell before the handover to a target cell could be completed. For example, when a UE leaves a pico-cell, it may happen that the coverage border of the pico is so sharp, that the UE fails to receive any handover command towards a macro before loosing coverage to the pico, see FIG. 5 or 6.
FIG. 6 illustrates a handover region of a pico/macro cell change versus a macro/macro cell change. A network comprises a pico cell 638, a marco cell 640a, and a further macro cell 640b. An abscissa 644 of the diagram may represent a Reference Signal Received Power (RSRP), and an ordinate 646 of the diagram may represent a distance. A curve 666 may represent the RSRP perceived by a UE from the macro cell 640a, a curve 668 may correspond to the RSRP perceived by a UE from the pico cell 638, and a curve 670 may represent the RSRP perceived by the UE from the another macro cell 640b. A handover region 672 from the macro cell 640a to the pico cell 638 and vice versa is small compared to a handover region 674 between the macro cells 640a, 640b. 
Similar problems could occur when a UE connected to a macro cell suddenly enters a pico cell on the same carrier: It could now happen that the control channels of the pico cell interferes with the signals that the UE needs to receive from the macro cell in order to complete the handover, and the handover thus fails.
In order to investigate the consequences of increased handover failures and solutions to mitigate those, 3GPP is currently working on evaluations and technical solutions for amendments, as described in TR 36.839, e.g. V11.1.0 (2013-01).
In the following, key performance indication (KPI) degradation and a need for drive testing is described. In this respect, the term “key performance indication” may particularly denote information collected by a network, which information may relate to a performance characteristic of the network such that a corresponding managing network operator may accordingly adapt the network. For example, a KPI may relate to handover failures and may indicate information such as how often a handover may occur, in which area the handover may occur, a reason for the occurrence of the handover etc. The term “drive testing” may particularly denote a procedure in which dedicated testing device, e.g. a user equipment, may move through the network, e.g. may drive around”, and may test network characteristics related to e.g. connectivity. In one option, an entity, e.g. a software may be installed spatially fixed in the network and may collect corresponding information from user equipments in the network.
Today it is very difficult to determine if a KPI problem experienced at a certain location in a radio network is due to that a Cell does not receive UE transmission or if it is the UE that does not receive the cell transmission or both. The current typical way of trouble shooting is to make drive testing and collect both Cell traces with time stamped events/transmissions and UE trace with events/transmissions is collected from the UE's used for drive testing. Here, the term “trace” may refer to a collection of logged information.
In 3GPP efforts have been made to support that UE collect some information when experiencing problems with the connection or problems in getting access to the system and then when connectivity is established to the network (NW) at a later time when a connection is established the NW can ask the UE to transmit the collected information. The collected information has time stamp information based on an UE internal clock and also location information.
Drive testing and using specific UE's for drive testing may not always be able to discover intermittent faults or drive into locations where the problem actually occurs. If it is a UE vendor specific problem the UE used for drive testing may not have the same kind of fault as some of the UE's used by subscribers in the network. On top of that regular drive testing is typically very expensive. There is a large cost for collecting the data and also a cost when data is analyzed. The data analysis can be costly and difficult due to that drive testers need to collect all data on rather detailed level and hope that the intermittent fault appears and are captured in the data collected during drive testing amongst the large amount of data collected.
Assuming a system where a UE can be simultaneously connected to several cells, it is currently unclear how the UE shall evaluate radio link failures and how the system shall react upon these radio link failures or other connectivity issues of some of the maintained connections.
Moreover, KPI evaluation by the radio network for UEs experiencing radio link problems in certain locations at a certain time is problematic due to the degraded connectivity to the UE in these situations. With the current system, the evaluation cannot be done immediately after the fault and is usually based on reports or (costly) drive tests. An immediate adaption of the system possibly improving the KPIs is thus not possible.